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TITLE:  The  Role  of  The  Operational  Command 

in  Acquiring  C3  Systems 

AUTHOR:  F.  Wah .  Leong,  Colonel ,  USAF 

The  Air  force  has  not  been  successful  in  acquiring 

Communication  Command  and  Control  <C3)  systems.  The  failure 

of  the  acquisition  to  NORAD  Cheyenne  Mountain  Complex 

Improvement  Program  <427M>  is  one  of  the  notable  failures 

discussed  briefly.  This  paper  describes  some 

characteristics  of  C3  systems  that  necessarily  link  the  user 
or  operation  command  to  the  success  of  C3  acquisitions. 

Then  the  specific  role  of  the  operational  command  in  C3 
acquisition  is  discussed  with  hope  of  showing  the  user  how 
he  can  structure  his  command  to  acquire  C3  systems. 
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Colonel  F.  Wah  Leong  <MA  in  Mathematics,  University  of 
Missouri)  has  worked  computer  systems  and  C3  systems 
acquisitions  most  of  his  21  years  in  the  Air  Force.  He  was 
the  Aerospace  De tense  Command's  technical  representative  -for 
the  acquisition  of  the  ground  communication  segment  for  the 
Defense  Support  Program.  In  1 963  he  headed  up  a  mission 
analysis  effort  to  define  space  surveillance  systems 
requirements  for  the  late  1970s.  As  a  captain,  he  was  the 
user  project  officer  for  the  design,  development,  and 
implementation  of  a  computer  security  system  for  the 
computer  system  that  served  the  Air  Staff  and  the  Office  of 
the  Secretary  of  Defense.  He  was  assigned  to  the  Air  Staff 
in  1977  to  sta-tf  the  approval  of  data  automation 
requirements  for  electronic  warfare  systems,  avionics 
support  systems,  and  intelligence  systems  in  the  Air  Force. 
When  he  transferred  to  the  Directorate  of  Command  and 
Control  and  Telecommunications  in  the  Pentagon  he  was 
responsible  for  the  planning  end  programming  of  funds  for 
the  strategic  command  and  control  systems  in  the  Air  Force. 
In  1981  Colonel  Leong  was  assigned  as  the  Deputy  Director  of 
Architecture  in  the  System  Integration  Office  under 
CINCNORAD.  After  a  year  in  the  job,  Colonel  Leong  spent  the 
next  three  years  acquiring  computer  systems  to  replace  the 
existing  NORaD  command  and  control  system.  Colonel  Leong  :  ? 
a  graduate  of  the  Air  War  Col  lege  Class  of  1906. 
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INTRODUCTION 


In  September,  197?  the  North  American  nerospace  De+en=e 
Command  (NORAD)  Cheyenne  Mountain  Complex  Improvement 
Program  (427M)  achieved  equivalent  operational  capabi  lit. 
(EOC).  The  term  EOC  was  uniquely  coined  for  Program  427  to 
indicate  that  the  new  system  achieved  a  level  o-f  ope,  ational 
capability  equal  to  the  capability  o-f  the  systems  being 
replaced.  Thus,  Program  427M  which  could  not  meet  the 
speci-fied  user  requirements,  was  more  than  three  years 
behind  schedule,  had  doubled  in  cost  to  more  than  $200M,  and 
had  more  than  2000  errors  in  its  software  achieved 
operational  status.  There  is  little  debate  on  whether  or 
not  the  427M  acquisition  was  a  -failure.  To  make  matters 
even  worse,  two  significant  events  occurred  within  nine 
months  after  the  EOC  date  which  seriously  questioned  the 
sufficiency  of  the  technical  requirements  identified  for  the 
427M  System.  These  two  events  were  the  NORAD  false  alarm 
incidents  that  took  place  in  November  197?  and  June  1980. 

The  acquisition  of  this  complex  communications,  command 
and  control  (C3)  system  has  been  studied  in  the  most  minute 
detail.  Studies  on  the  427M  System  were  accomplished  bv  Air 
Force  Systems  Command's  Electronic  Systems  Division,  Air 
Force  Inspector  General,  General  Accounting  Office,  DOD  Blue 
Ribbon  Panel  with  industry  experts,  Congress,  Joint  Chiefs 
of  Staff,  and  numerous  technical  consultant  companies.  My 
object  is  not  to  reiterate  all  that  has  been  said  by  these 
studies.  My  purpose  is  to  use  the  acquisition  of  the  427M 
System  and  its  follow-on  replacements  to  describe  how  the 


veer  or  operational  command  tor  a  C3  system  should  structure 
' se 1 t  to  successful ly  acquire  these  kinds  ot  systems. 
i  r  =  t  ,  I  will  define  wh at  a  C3  sy s t em  is  and  will  de sc r i be 
r ow  the  nature  of  C3  systems  requires  extraordi nary  user  or 
operational  c ommand  i nuol vement .  Then  I  will  rely  on  my 
o-erall  C3  acquisition  experience  and  my  specific  experience 
wth  the  acquisition  of  427M  System  and  its  replacement 
programs  to  describe  the  role  of  the  user  or  operational 
command  in  acquiring  C3  systems.  Not  all  of  the  suggestions 
and  ideas  presented  here  were  implemented  at  NORAD/Space 
Command  so  they  are  not  necessarily  tried  and  proven.  One 
has  to  accept  these  ideas  for  face  value  since  no  one 
organization  has  fully  implemented  this  approach  and  carried 
it  to  a  successful  conclusion.  However,  with  the  absolute 
vacuum  within  the  technical  literature  about  the  role  of  the 
user  or  operational  command  for  C3  acquisitions,  I  believe 
this  kind  of  discussion  is  sorely  needed. 


CHAPTER  I  I 


De-fining  C3  Systems 

The  Armed  Forces  Communications  and  Electronics 
Association  (AFCEA)  Command  and  Control  System  Acquisition 
Study  defined  command  and  control  systems  as  systems  which 
augmen  t  the  decision  processes  of  operational  military 
commanders  and  their  staffs,  including  those  which 
constitute  weapon/platform  control  systems  as  well  as 
intelligence  information/exploitation  and  management/force 
planning  and  control  aids.  (1)  I  would  only  add 
communications  to  the  definition  of  command  and  control 
systems  because  these  systems  must  receive  the  data  they 
process  and  assimilate  it  through  some  media  of 
communication  and  similarly  they  must  communicate  with  the 
commander  and  his  staff  to  provide  the  information  he  needs 
to  make  his  decisions.  In  short,  communications,  command  and 
control  <C3)  systems  directly  support  decisions  by 
operational  military  commanders.  The  NORAD  command  and 
control  system  which  encompasses  the  427M  systems  and  other 
subsystems  within  Cheyenne  Mountain  Complex  is  a  C3  System. 

A  second  example  of  a  C3  System  is  the  Data  System 
Modernization  Program  which  supports  the  on-orbit  control  of 
satellites  for  the  Air  Force.  On  the  other  hand,  automated 
management  information  systems  processing  financial, 
personnel ,  or  logistical  information  are  not  C3  systems. 

The  common  thread  is,  and  should  be,  that  the  03  systems 
must  provide  direct  information  to  augment  commander 


More  often  than 


decisions  on  oper a  t i on  a  1  military  i ssue  s . 
not,  C3  systems  must  obtain,  process  and  dissiminate  the 
information  for  the  operational  commander  in  a  timely 
fashion.  Timely  means  within  seconds  and  minutes  as  opposed 
to  hours  and  days.  It  is  this  time  line  requirement  that 
ususally  separates  C3  systems  from  management  information 


sys  t  ems . 


CHAPTER  III 


Nature  of  C3  Systems 

When  one  researches  the  technical  literature  on  C3 
System  acquisition  and  system  acquisition  in  general,  he 
•finds  no  common  solution  or  recommended  approach  to 
acquiring  C3  systems  successful  1 y.  Unfortunately,  this 
paper  does  not  propose  to  have  found  the  magical  answer  to 
the  problems  confronting  C3  system  acquisition.  What  I  did 
find  in  my  research  was  a  general  confirmation  of  the 
importance  of  user  involvement  to  the  success  of  C3  system 
ac qu i s i t i on s .  In  his  Air  War  College  paper,  then  Colonel 
James  Cassity,  in  describing  the  system  acquisition  process 
stated  that  the  requirements  of  the  operating  command  can  b 
met  when  it  (the  operating  command)  acts  as  a  full  partner 
in  the  acquisition  process,  assisting  in  developing  the 
request  for  proposal,  selecting  the  source,  and  in  all 
phases  of  design  and  deve 1 opmen t . < 2)  Although  Colonel 
Cassity  meant  for  this  partnership  to  apply  to  the 
acquisition  of  weapons  systems  in  general,  I  claim  that  the 
unique  nature  of  C3  Systems  demands  a  total  commitment  of 
involvement  by  the  user  or  the  operational  command. 

To  substantiate  this  claim,  I  will  describe  these 
characteristics  of  C3  systems  that  require  the  total 
participation  of  the  user  in  the  acquisition  of  these 
systems .  These  characteristics  are:  C 3  system  requirement 
are  constantly  changing;  C3  systems  must  interface  with 


other  systems ;  a n d  C 3  s v s  t e  m  s  s  u  p  p or  t  wartime  o  p  erst i o n a  1 
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missions.  In  his  article  on  the  C3  acquisition  process 
Robert  Dean  stated  that  C3  systems  are  intrinsically 
evolutionary,  partly  because  they  must  operate  in  a 
constantly,  but  not  always  predictably,  changing 
environment,  and  because  they  must  support  human  decision 
making,  a  process  that  cannot  be  completely  specified  a 
pr i or i  .  (3)  An  excellent  ex  amp  1 e  of  this  changing 
e  n  v i ronmen  t  is  the  threat  that  the  427M  program  had  to 
counter  during  eight  years  of  development  and  the  last  seven 
years  as  an  operational  system.  In  the  early  1970s  the 
a  tmosp  h  e  r i c  bombe  rs  and  intercontinental  ba 1  1  i s  t i c  mi ss lies 
constituted  the  major  threat  to  the  defense  of  the  North 
American  continent.  By  the  mid-1970s  the  atmospheric  threat 
practically  evaporated  and  the  predominant  threat  was  the 
sea  launched  ballistic  missiles  and  intercontinental 
ballistic  missiles.  During  the  late  1970s,  and  early  1980s, 
the  emphasis  on  the  427M  system  turned  to  the  space  threat 
and  support  of  space  operations  with  the  space  shuttle.  Now 
the  emphasis  has  turned  full  circle  to  the  atmospheric 
defense  arena  where  we  must  counter  the  effect  of  bombers 
launching  cruise  missiles.  While  the  threat  evolved  the 
fundamental  requirements  also  changed  from  being  able  to 
detect  a  massive  attack  on  the  U.S.  to  being  able  to  detect 
limited  nuclear  attacks  with  the  highest  degree  of 
cer  taint  -  .  T  hi  s  changing  e  n  •  >  i r on me  n  t  provides  s  ome  i n  s i oh t 
as  to  •••ir.  .  the  4  2~M  3-  stem  was  on  1  able  to  satisf*  the 
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ting  s . s  terns  after  eight  y ears  of 


1  e  e  ’  o  p  m  e  r  *■  .  It  i  s  difficult  to  hit  a  moving  target  when 


one  has  to  develop  and  modify  over  11  million  lines  of  codes 
that  make  the  427M  system  function.  From  these  comments  one 
can  also  understand  why  only  the  user  who  best  understands 
the  changing  environment  should  be  the  one  to  work 
continuously  with  the  developer  to  properly  change 
requirements  and  to  establish  priorities  as  required.  But 
even  the  user  cannot  predict  the  changing  requirement. 

C3  System  must  also  evolve  to  support  the  human 
decision-making  process  because  we  know  so  little  of  this 
complex  process.  One  way  to  minimize  the  changes  here  is 
for  the  user  to  analyze  the  details  of  his  dec i s i on-mak i nq 
process  to  identify  necessary  and  sufficient  conditions  for 
determining  a  course  of  action.  Unfortunately,  this  kind  of 
work  is  usually  foreign  to  personnel  in  a  user  or 
operational  command.  The  other  way  to  minimize  the  changes 
is  to  specify  in  our  requi remen  ts  the  type  of  flexibility 
that  readily  permits  the  C3  system  to  accommodate  the  latest 
desire  to  see  this  kind  of  information  in  a  new  and 
different  format.  Only  the  user  or  operational  command  can 
do  any  meaningful  work  in  the  decision-making  process  as  it 
appl les  to  the  user's  system  and  mission.  For  anyone  else 
to  do  this  results  in  an  academic  exercise  of  little 
utility.  This  is  not  to  say  that  the  user  cannot  get  help 
to  do  such  analysis  work,  but  he  must  be  the  prime  mover  in 
any  effort  to  insure  what  is  done  is  applicable  to  the  real 
wor Id  situation. 

The  second  characteristic  is  that  C3  systems  are 
generally  sub-systems  of  larger  complex  systems  and  must  by 
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necessity  interface  to  many  other  systems  or  sub-systems. 

The  problem  that  arises  -from  this  particular  characteristic 
is  that  C3  systems  become  very  complex  systems  to  build 
because  of  the  vast  number  of  inter-faces  to  other  systems. 
Furthermore,  usually  the  user  of  the  system  has  little  or  no 
control  over  the  systems  he  must  interface  to.  That  is  to 
say  that  a  system  to  be  interfaced  to  /our  C3  system  may  be 
owned  by  a  different  major  command  or  even  a  different 
service  where  the  C3  user  has  absolutely  no  technical 
responsibility  or  mission  authority  for  affecting  interface 
requirements  to  the  system.  Consequently,  one  could  be 
building  a  specific  interface  to  system  A,  but  before  you 
get  the  system  operational,  System  A  modifvs  its  interface 
to  external  systems  and  now  you  cannot  interconnect  with 
System  A  with  the  new  change.  The  question  becomes  who 
changes  their  interfaces7  One  can  begin  to  understand  this 
problem  when  you  deal  with  systems  such  as  the  427M  that 
must  interface  to  literally  hundreds  of  other  systems.  ms 
the  427M  became  operational  in  the  early  1980s,  there  were 
over  120  different  technical  interfaces  to  the  427M  s-stem 
in  the  NGRAO  Cheyenne  Mountain  Complex.  We  on  I  •  formal  I  < 
recognized  that  the  427M  system  was  a  sub-s>stem  of  the 
overall  Tactical  Warning  and  Attack  Assessment  System  in  the 
fall  of  1980  after  the  Air  Force  Inspector  Genera'  performed 
a  management  review  of  the  Air  Force  organ i :at i onal 
structure  and  units  tasked  with  the  mission  of  defending  the 
North  American  continent  for  aerospace  attack.  The  re-  -ew 
also  recognized  the  need  to  identify  *  technical  system 
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manager  for  the  total  Tactical  Warning  and  Attack  Assessment 
System  whose  authority  could  transcend  service  and  joint 
agency  boundaries.  The  manager  was  given  the  tech  ini  cal 
responsibility  -for  integrating  the  sub-systems  into  the 
whole.  What  was  key  here  was  that  the  427M  user  or 
operational  command  was  given  the  system  integration  role. 
The  integrator  -for  C3  systems  must  be  the  organization  that 
is  most  knowledgeable  with  the  system  and  has  the  most  to 
gain  by  effectively  employing  the  system.  Most  often  this 
is  indeed  the  user  or  the  operational  command.  The  role  of 
the  system  integrator  is  to  make  certain  the  sub-systems 
work  together  when  they  are  i n terconnec ted .  When  the  user 
accomplishes  this  job  he  will  simplify  and  limit  the  number 
of  technical  interfaces  within  a  total  system.  After  this 
is  done  --  and  it  takes  literally  years  to  do  —  the  C3 
system  and  its  replacements  will  become  easier  to  develop 
an d  to  ma i n  t  a i n . 

The  ini tial  comment  a  user  or  operational  command  makes 
when  one  suggests  that  they  become  the  system  integrator  for 
a  C3  system  is  that  operators  do  not  have  the  technical 
expertise  to  do  the  integration  job.  They  then  try  to 
convince  the  developer  to  take  over  the  integration  task. 
Well,  I  am  strongly  convinced  that  the  developer  does  not 
have  the  motivation  to  perform  the  integrator  function  which 
b-  necessi  t  /  does  not  end  when  the  C3  system  becomes 
operational .  Under  m»  concept,  the  system  integrator  exists 
for  the  1 i fe  of  the  system  to  insure  that  all  proposed 


chances  do  not  adversely  affect  the  total  system. 
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of  technical  capability  can  be  overcome  by  the  operational 
command.  But  this  takes  time  and  a  complete  commitment  on 
the  kind  of  people  the  user  needs  to  hire  and  reward  when 
they  have  proven  themselves.  When  a  user  has  had  the 
opportunity  to  be  the  technical  system  integrator  -for  a  C3 
system,  that  system  becomes  more  manageable  to  acquire  a 
replacement  to r  and  the  replacement  system  will  be  more 
effectively  operated. 

The  third  char ac ter i st i c  is  that  one  must  understand 
that  C3  systems  must  function  in  a  wartime  environment  This 
means  that  the  care  and  feeding  of  a  C3  system  is  more 
critical  than  the  care  and  feeding  for  non-wartime  systems. 
It  is  easy  to  look  at  the  parts  of  a  C3  system  and  come  to 
the  conclusion  that  since  C3  systems  are  composed  of 
computers,  communication  lines,  graphic  devices  and 
software,  they  are  just  complex  management  information 
systems.  Nothing  could  be  further  from  the  truth  and 
nothing  can  get  us  into  more  trouble  if  we  continue  to  let 
such  thoughts  and  complacency  guide  our  actions  and 
acquisition  policy.  It  is  not  sufficient  that  a  C3  system 
works  correctly  in  a  non-host ile  environment.  A  C3  system 
must  be  designed  to  function  in  a  wartime  situation  when 
other  systems  and  communication  lines  do  not  work.  It  may 
be  forced  to  operate  in  a  degraded  mode.  For  example,  can 
the  software  run  on  less  than  the  optimum  number  of 
processors7  I  claim  that  only  the  user  or  operational 
command  can  fully  understand  the  impact  of  a  C3  system  not 
working  in  a  wartime  environment.  Consequently,  the  user 
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must  be  the  one  asking  the  tough  questions  on  whether  a 
specific  requirement  will  cause  the  system  not  to  function 
properly  in  a  wartime  environment.  Furthermore,  the  user  i 
the  right  person  -for  insuring  that  the  C3  system  functions 
in  wartime  because  he  is  the  one  that  suffers  the 
consequences  if  the  system  should  fail.  C3  systems  are  mor 
than  force  multipliers.  The  427M  system  must  provide 
CINCNGRAD  the  information  necessary  to  give  adequate  and 
unambiguous  warning  information  to  the  National  Command 
Authorities.  If  the  warning  is  not  timely  or  if  it  is 
incorrect,  the  failure  could  result  in  the  destruction  of 
our  country  as  we  know  it  today. 

In  summary,  only  C3  system  users  can  understand  and 
articulate  the  changing  requirements  for  these  systems,  can 
manage  and  integrate  the  system  within  the  overall  system, 
and  can  insure  that  the  C3  system  works  in  a  wartime 
environment.  This  is  precisely  why  the  user  or  operational 
command  must  be  a  ful  1  partner  and  total  1 y  involved  wi  th  th 
deve leper  in  acquiring  C3  systems .  Little  is  written  abou t 
how  the  user  or  operational  commands  should  acquire  C3 
systems.  What  I  hope  to  impart  to  those  commands  involved 
in  acquisition  is  some  ideas  on  how  they  can  prepare 
themselves  to  acquire  new  C3  systems. 


CHAPTER  IU 


ROLE  OF  THE  USER  OR  OPERATIONAL  COMMAND 
A.  User's  Perspective 

As  the  user  or  operational  command  participate  in  an 
acquisition  o-f  a  C3  system,  it  is  essential  that  each 
individual  representing  the  user  understands  what  his 
fundamental  objective  is.  By  the  same  token,  the  user  need 
to  understand  what  really  drives  the  representatives  of  the 
developing  command.  Let's  -first  address  the  developer. 
Developing  organizations  are  usually  organized  under 
entities  called  system  program  offices  or  SPOs  which  are 
headed  up  by  a  program  manager.  The  program  manager  will 
generally  be  competing  against  other  program  managers  in  th 
functional  organization  he  is  in.  Because  each  program  is 
totally  different,  the  primary  evaluation  tool  that  is  used 
’.o  evaluate  the  performance  of  these  program  managers  is 
schedule  and  cost.  The  program  manager  wants  to  know 
whether  the  project  is  on  schedule  and  within  the  projected 
cost.  Certainly,  the  developer  or  program  manager  wants  t  r. 
contractor  to  satisfy  the  technical  spec i f i ca t i on =  ana 
support  requirements,  but  rest  assured  that  when  cost  and 
schedule  are  threatened,  requirements  become  seconder.. 

This  type  of  motivation  is  not  necessarily  wrong,  but  it  is 
real.  LJhat  is  important  about  the  developer  s  per  spec  t  e 
is  that  the  user  understand  that  his  perspective  shov'd 
provide  the  counter -balance  to  the  acquisition  partnership. 
T hi e  user  s  pr  imar>-  perspective  should  be  to  insure  that  the 
system  works  to  support  the  wartime  mission.  Llh  i  le  thi  s 


seems  obvious,  the  user  representatives  cio  not  tul  1  >  suppor 
this  perspective.  The  reason  -tor  this  misunderstanding  is 
because  no  one  evaluates  the  user  representatives  on  the 
basts  of  whether  the  C3  system  works.  When  the  C3  system 
does  not  work  properly  or  meet  the  specifications,  the  user 
blames  the  developer  or  the  contractor.  One  might  sa -  that 
you  cannot  expect  the  user  to  be  responsible  for  the  "‘or  <■  o 
a  contractor  they  had  no  control  over.  While  this  ma>  be 
v  e  r  >■  true,  who  is  really  going  to  be  concerned  about  the 
system  work i nq  if  the  user  doesn ' t7  Clearly  the  contractor 
wants  the  system  to  work,  but  his  primary  motivation  is  to 
mak e  money.  The  user  representatives  must  be  held 
accountable  for  identifying  problems  with  the  system  as  it 
is  being  developed  and  not  just  discover  the  problem  as  it 
is  being  tested  in  the  operational  environment.  Before  we 
can  successfully  acquire  C3  systems,  the  user  has  to 
undertake  the  responsibility  of  mak ing  certain  the  svs  t  em 
works  we  1  I  enough  to  do  the  mission. 

B.  Organizing  and  Manning  to  Acquire  C3  Systems 

Most  operational  commands  use  their  existing  Deputy- 
Chief  of  Staff  (DCS)  structure  to  support  the  acquisition  o 
C3  systems.  Carious  members  of  the  functional  staff 
participate  in  the  acquisition  process.  For  example,  the 
DCS  Plans  people  usually  provide  an  interface  to  the  -system 
program  office  for  the  commmand,  but  their-  concern  wi  th  the 
acquisition  is  with  the  program  schedule  and  cost  because 
planning  and  funding  is  what  the  DCS  Plans  does  for  a 


command.  Representatives  -from  the  DCS  Operations  are 
concerned  about  the  operational  concept  -for  this  new  C3 
system.  But  because  the  staff  is  consumed  by  the  current 
operational  staff  problems,  acquisition  takes  a  back  seat 
with  a  Lieutenant  assigned  the  job  on  a  part-time  basis. 
Similarly  the  DCS  Logistics  representative  insures  the 
logistic  support  plans  are  properly  implemented,  but  often 
this  -function  is  done  on  a  part-time  basis.  Who  ever  heard 
of  a  person  in  an  operational  corrimand  getting  promoted  earl 
because  he  did  a  good  job  in  acquiring  a  C3  system"-1  Well, 
it  just  doesn't  happen.  By  the  same  token,  no  one  in  an 
operational  command  gets  fired  if  the  C3  system  doesn't 
work.  One  might  say  that  "so  what  if  the  operational 
command  is  not  organized  to  acquire  systems".  "That’s 
System  Command' s  job."  Well,  this  is  where  I  strongly 
disagree.  I  be  1  i eve  that  the  user  is  not  organized  to 
acquire  systems,  but  I  don't  believe  that  the  user  can  1 e av 
the  job  to  the  developer.  If  the  user  wants  to  successful! 
acquire  C3  systems,  he  has  to  organize  to  do  just  that.  Th 
development  community  has  learned  that  you  cannot  acquire 
systems  without  dedicating  effort  to  that  task.  The  user 
can  learn  f  r  om  these  lessons.  An  independent  organization 
within  the  operational  command  is  needed  to  do  the 
acquisition  tasks  for  the  user.  This  organization  should 
not  have  an.  of  the  other  staff  functions  and  should  be  a t- 1 
t o  c ommu n i cate  di rec  t I  *  across  Deputy  Chief  of  Staff  lines 
in  order  to  obtain  c  oor  dmati  on  on  s  ■  stem  r  e  q  u  i  r  eme  n  t  s  . 
specifications,  a n d  modifications.  The  acquisition  unit 


will  represent  the  interest  of  the  various  functional  staff 
elements,  but  now  you  have  someone  in  the  operational 
command  who  is  solely  responsible  for  the  acquisition  of  a 
C3  system  for  the  user.  Usually,  a  command  is  involved  with 
multiple  system  acquisitions.  Each  C3  system  that  is  being 
acquired  should  have  a  mini  system  program  office  manned 
with  personnnel  with  a  variety  of  technical  and  operational 
background.  These  should  include  personnel  with  computer 
acquisition  expertise,  including  both  hardware-  and 
software-development  expertise,  computer  graphics 
technology,  C3  system  acquisition  experience,  communication 
engineering  experience,  electronic  maintenance  experience, 
and  operational  experience  with  the  C3  system.  Finally, 
stability  of  the  personnel  assigned  is  absolutely 
imperative.  This  means  at  least  three  years  on  station  for 
people  working  the  C3  acquisition.  Key  leadership  positions 
should  have  back-up  personnel  in  training  that  are  obtaining 
the  specific  experience  to  replace  the  leaders  as  they  are 
reassigned,  sometimes  unexpectedly.  Good  people  are  the  key 
to  working  acquisitions  successfully. 

C.  Requirements  Development 

Most  major  operational  commands  wait  until  they  have  to 
replace  a  C3  system  before  they  begin  the  requirement 
def  i  n  i  t  i  on  process  to  replace  the i r  ex i st i ng  system .  Bv  th i  s 
time  they  are  too  late  to  do  the  analysis  needed  to  properl • 
describe  what  they  want.  There  is  no  question  that  as  T 
discussed  earlier,  the  changing  environment  and  supporting 
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the  decision-making  process  make  the  determination  of 
technical  requirements  -for  C3  systems  a  difficult  task.  But 
it  is  just  as  important  to  know  that  the  operational 
commands  do  not  do  a  good  job  in  developing  C3  requirements. 
Getting  “behind  the  eight  ball"  is  only  part  of  the  problem. 
Usually  the  operational  command  does  not  have  sufficient 
numbers  of  people  with  the  blend  of  technical  and 
operational  experience  to  adequately  define  the 
requirements.  Furthermore,  the  process  of  developing 
requirements  within  an  operational  command  staff  always 
leads  to  a  system  conceived  by  committee.  There  should  be  a 
strong  competent  element  within  the  staff  that  can  consider 
the  imputs  from  the  staff,  but  in  the  end  makes  the 
determination  as  how  the  system  should  work.  The  user- 
should  first  begin  the  requirements  development  process  soon 
after  the  critical  design  review  of  the  new  C3  system  that 
will  be  replacing  the  current  system.  Thus,  once  we 
understand  what  will  be  operational  in  the  next  three  to 
five  years,  we  should  begin  the  effort  to  replace  it.  The 
first  step  is  to  formulate  the  conceptual  definition  of  the 
follow-on  replacement  systems.  The  user  needs  to  examine 
the  technology  as  what  is  being  fielded  now  and  within  the 
next  ten  years  that  could  be  applied  to  a  future  C3  system. 
He  should  look  at  projections  of  the  threat  to  understand 
what  the  system  must  counter.  And  finally,  he  must  look  at 
the  long-term  strategy  trends  that  will  dictate  how  the 
future  system  will  be  expected  to  function  in  the  future 
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en v i r onmen t  . 


The  operational  command  can  and  should  obtain 


assistance  in  the  conceptual  definition  process.  For 
example.  Space  Command  hosted  technology  panels  where  we 
invited  members  o f  industry  and  academia  to  discuss 
technology  solution  to  specific  requirements.  However,  the 
operational  command  needs  to  guard  against  the  tendency  of 
letting  the  technologist  do  all  the  work.  It  is  too  easy 
for  the  operators  to  let  the  technicians  take  charge  of 
these  kinds  of  tasks. 

Once  the  user  is  able  to  develop  the  concept i onal 
definition  of  the  follow-on  system,  the  next  step  is  the 
concept  of  operations.  The  user  needs  to  understand  if  he 
can  do  the  mission  with  this  new  conceptual  C3  system. 
Operational  concepts  for  C3  systems  are  much  more  difficult 
to  develop  than  for  weapon  systems.  As  a  consequence,  we 
often  do  not  formulate  these  concepts  until  after  03  systems 
are  implemented.  The  development  of  the  operational  concept 
may  result  in  changes  to  the  conceptual  definition  of  the 
system.  This  iterative  process  is  to  be  encouraged,  but  the 
changes  should  be  formally  done  and  all  the  rationale  for 
recommend i ng  changes  to  the  system  definition  must  be 
documented  to  provide  a  record  of  why  decisions  were  made. 
This  record  provides  the  continuity  of  management  as  key 
individuals  are  replaced  during  the  process.  When  we  decide 
the  follow-on  system  can  be  operated  and  supported  to 
perform  the  mission,  the  user  needs  to  develop  the  initial 
drafts  of  the  technical  specification  that  will  be  provided 
to  the  developer.  Spe cif icati on  dev  e 1 opme  n  t  is  u  s u  a  1  1  y 
reserved  for  the  developer,  but  I  believe  that  prel  iminar:- 


specifications  development  by  the  user  crystallizes  early 
in  the  requirements  deve 1 opmen t  process  is  what  is  wanted. 
When  the  user  can  perform  these  tasks:  conceptual 
definition,  operational  concept,  and  preliminary 
specifications,  he  becomes  a  sophisticated  user  who  knows 
what  he  wants.  This  kind  of  preparation  will  not  eliminate 
changes  to  C3  systems,  but  it  will  assist  the  developer  in 
understanding  what  the  end  product  should  be  and  how  to 
achieve  it. 

D.  Integration  and  Implementation 

Integration  is  defined  as  the  process  of  making 
sub-systems  work  as  an  overall  system.  Because  C3  systems 
are  sub-systems  of  an  overal 1  system  and  because  these  C3 
systems  must  interface  with  numerous  other  systems  to 
accompl i sh  their  missions.  The  role  of  the  integrator 
becomes  essential  to  the  successful  acquisition  of  a  C3 
system.  If  the  user  or  operational  command  is  responsible 
for  the  operations  of  the  total  overall  system,  then  he 
should  be  the  system  integrator.  The  user  may  get  extensive 
support  from  various  contractors,  but  he  alone  must  be 
singularly  responsible  for  integrating  the  sub-systems.  The 
best  individual  to  be  the  system  integrator  is  the  person 
who  heads  up  the  dedicated  acquisition  agenc ■  within  the 
operational  command.  This  integrator  should  manage  the 
acquisition  of  all  systems  for  a  user  and  have  sole 
responsibility  for  defining  interface  requirements  to  all 
user  systems.  He  also  is  the  focal  point  within  the  command 


who  works  interface  requirements  to  systems  that  are 
external  to  the  operational  command.  An  essential  on -going 
■function  o-f  the  systemi  integrator  is  to  establ  i  sh  standard 
interface  requirements  tor  user  C3  and  weapon  systems  and  to 
enforce  these  standard  interfaces  in  the  non-standard 
systems  over  time.  The  development  and  maintenance  of 
standards  is  a  difficult  and  time  consuming  effort  that  must 
be  accomplished  by  the  user-  because  the  developer  will  not 
be  around  long  enough  to  perform  this  function.  The 
integration  must  be  kept  separate  from  the  developing 
function  because  of  the  potential  conflict.  Two  developers 
cannot  easily  resolve  the  technical  interface  problems  that 
may  exist  between  them.  But  an  integrator  can  view  he 
problem  as  a  third  party  and  enforce  the  resolution 
decision. 

The  system  integrator  may  also  find  it  necessary  to 
develop  a  technical  architecture  for  his  overall  systemi  to 
provide  a  technical  road-map  of  how  the  overal  1  systemi  wi  1  1 
look  and  operate  in  the  future.  The  architecture  becomes, 
useful  on  1  y  if  it  is  a  formal  document  that  must  be  compl  ted 
with  and  can  only  be  changed  after  a  thorough  evaluation 
process.  The  architecture  in  effect,  provides  a  way  to 
control  the  overall  systemi  and  prohibits  incompatible  and 
non-standard  major  changes  to  the  individual  sub-systems. 
When  you  establ i sh  controls  on  the  overal 1  system  that 
contain  a  l 3  system,  you  greatly  enhance  your  efforts  to 
successfully  acquire  the  replacement  C3  systems. 

Implementation  of  a  C3  system  requires  significant 


support  of  the  user. 


The  reason  tor  this  is  fairly  basic. 


Few,  i  f  an-,  weapons  systems  are  changed  out  as  the y  a r  e 
operating.  But  on  the  other  hand,  that  is  exactly  what  is 
done  with  most  C3  systems.  For  example,  the  operational 
command  must  operate  the  existing  C3  system  in  parallel  with 
the  new  C3  system  in  order  to  insure  that  the  new  system  can 
assume  the  operational  mission.  This  is  no  small  feat. 
Facility  requ i remen ts  must  support  two  operating  systems  and 
one  must  haue  the  operators  and  maintainers  to  handle  both 
systems  simultaneously.  In  addition  to  careful  planning  and 
programming  for  the  additional  resources  and  personnel  ,  a 
separate  test  development  and  training  facility  is  an 
absolute  requirement  for  one-of-a-kind  C3  systems.  This 
facility  permits  a  C3  system  to  be  implemented  in  an 
off-line  environment  that  evaluates  the  operational 
env i ronmen  t.  This  test  facility  wou Id  al  1 ow  the  integrjti on 
process  to  be  tested  prior  to  actual  implementation.  The 
facility  also  serves  as  a  de v e  1  opme n t/ 1 e s t  bed  for  both 
software  and  hardware  changes  to  the  operational  system 
during  its  system's  life.  Space  Command  has  been  operating 
an  Off- Site  Test  Facility  for  its  427M  System  since  1981  and 
has  just  built  a  Test  Deuel opme  n  t  and  Training  Center  for 
the  four  major  C3  systems  which  will  replace  various 
portions  of  th  >27M  System.  The  benefits  for  such  a  test 
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Ear! i er  we  discussed  the  problems  the  user  or 
operational  command  had  in  planning  and  programming  -for  C3 
Systems.  Invariably,  the  operational  command  realizes  it 
needs  a  replacement  system  long  before  it  can  properly  -fund 
and  develop  the  system.  When  the  user  -finally  gets  to  the 
point  when  they  decide  to  program  funds  for  the  replacement 
system,  the  amount  to  be  programmed  is  no  better  than  a 
rough  estimate.  Years  later  when  the  developing  community 
performs  an  independent  cost  estimate  for  the  new  system, 
the  new  cost  estimate  will  exceed  the  original  estimate  by 
several  orders  of  magnitude  and  now  the  user  is  in  the 
position  of  settl ing  for  less  of  a  system  or  give  up  some 
other  programmed  system.  Consequently,  in  addition  to 
defining  the  requirements  earlier,  operational  commands  need 
to  establish  a  capability  to  cost  C3  systems.  This  means 
expending  manpower  and  resources  to  maintain  expertise  in  C3 
system  cost  analysis.  One  does  not  acquire  this  expertise 
oVv  •'night  so  the  user  must  understand  the  importance  of  this 
capability  and  invest  in  it  up  front. 


CHAPTER 


CONCLUSION 

The  user  or  operational  command  can  no  longer  afford 
the  luxury  of  approaching  C3  system  acquisition  in  a  casual 
manner.  The  user  must  make  the  total  commitment  in 
dedicating  the  resources  to  participate  fully  in  the 
planning,  programming,  development  and  implementation  of  Cl 
systems.  I  be  1  i eve  that  the  most  important  message  to 
commun i c a t e  is  that  the  user  must  not  become  the  developer 
even  though  he  may  possess  much  of  the  expertise  and  emplo,. 
many  of  the  techniques  of  the  developer.  The  operational 
command  must  undertake  its  share  of  responsibil ity  to  insur 
the  C3  system  works  to  support  the  wartime  mission. 
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